2026 年 7 月，Anthropic 的工程師 Thariq Shihipar 發了一篇文章，講 Claude Code 的 system prompt 怎麼為新一代模型重寫。社群拆解前後兩版的字數，發現從大約 2700 個字砍到 500 個字左右，只留不到兩成。
對 Opus 5 和 Fable 5 跑 coding evaluation 的結果是：no measurable loss — 沒有可測量的退步。
在 coding evaluation 這個維度上，那被砍掉的 80% 沒有在幫忙。
Anthropic 在文章裡放了一個 before / after 對比：
舊版指令："default to writing no comments. Never write multi-paragraph docstrings."
新版指令："write code that reads like the surrounding code: match its comment density, naming, and idiom."
舊版是規定式 — 不管什麼情境，一律不寫註解、不寫長 docstring。新版是適應式 — 看周圍的 code 怎麼寫，配合它。
這不只是措辭的差別。規定式指令假設「AI 不夠聰明，需要被明確告知每一步該做什麼」。適應式指令假設「AI 能從 context 判斷，只需要知道判斷的依據」。
「永遠不寫註解」這條規則的歷史背景是：早期模型會產生大量冗長、無意義的註解，需要一條硬規則來壓制。這在當時是合理的。
但 Opus 5 已經能從周圍的 code 判斷該不該寫註解、寫多少。「永遠不寫」這時候就從有用的護欄變成了有害的限制 — 在該寫註解的地方也不寫，因為規則說了不准。模型有判斷力，但規則不讓它用。
Anthropic 原文的說法是：這些限制曾經是為了避免最壞情況而存在的，但現在可以刪掉它們，讓模型用周圍的 context 和自身的判斷力來決定。
這就是那 80% 的真相。不是「寫太多所以 AI 讀不完」（那是 Day 1 的問題），而是「寫的內容本身在干擾 AI 的判斷」。同樣是指令太多，Day 1 是量的問題，這裡是質的問題 — 至少在 coding 這類模型已經有足夠判斷力的任務上是這樣。
但這不代表所有人都應該去砍 80%。Anthropic 砍的是自己的 system prompt — 他們比任何人都清楚哪些規則是為舊模型寫的。
安全相關的規則（「不要暴露 API key」「SQL 用參數化查詢」）不是因為模型笨才存在，而是因為犯錯的代價太高。這類規則不管模型多聰明都該留著。專案特有的約定（「commit message 用 conventional commits」「PR 標題不超過 70 字」）也是 — 這些資訊不在 code 裡，模型沒辦法從 context 推斷。
能砍的是那些「模型現在自己就會判斷」的規定式規則。不能砍的是模型無法從 context 得知的事實，和犯錯代價高到不值得賭的護欄。
1990 年代的 coding style guide 是幾十頁的文件，規定每一個大括號的位置、每一個縮排的寬度、變數命名的格式。新人入職第一件事是讀完這份文件，然後在 code review 裡被指出「第 47 頁說大括號要換行」。
然後 lint 工具出現了。ESLint 之類的工具把規則變成可執行的檢查，違反直接報錯。文件從「你應該遵守」變成「工具幫你擋」。
再後來 prettier 出現了。Prettier 的哲學是：連選擇都不用做，工具直接幫你格式化。幾十頁 style guide 裡關於格式的部分，被一行 npx prettier --write 取代了。
演化方向一直都是：執行者越聰明，規格越短。
但有一個關鍵差異：prettier 是確定性的 — 同樣的輸入永遠產生同樣的輸出。AI 不是。從規定式轉向適應式，換來的是靈活性，交出去的是可預測性。這也是為什麼前面說安全規則不能砍 — 在不能容忍變異的地方，你還是需要硬規則。
Anthropic 砍掉 80% 的 system prompt，跟團隊從幾十頁 style guide 換成 prettier 是同一件事。不是規則變少了，是執行者變聰明了，不再需要那麼多規則。但兩者都保留了不能自動化的部分 — prettier 不管你的變數該叫什麼名字，Anthropic 也沒砍掉安全規則。
延伸閱讀
iThome鐵人賽
看影片追技術